3GPP Long Term Evolution (LTE) is the fourth-generation mobile communication technologies standard developed within the 3rd Generation Partnership Project (3GPP) to improve the Universal Mobile Telecommunication System (UMTS) standard to cope with future requirements in terms of improved services such as higher data rates, improved efficiency, and lowered costs. GSM EDGE Radio Access Network (GERAN) is the radio access network in a GSM system. The Universal Terrestrial Radio Access Network (UTRAN) is the radio access network of a UMTS and Evolved UTRAN (E-UTRAN) is the radio access network of an LTE system. In a GERAN/UTRAN and an E-UTRAN, a User Equipment (UE) is wirelessly connected to a Radio Base Station (RBS) commonly referred to as a Base Transceiver Station (BTS) in GSM, as a NodeB (NB) in UMTS, and as an evolved NodeB (eNodeB or eNodeB) in LTE. An RBS is a general term for a radio network node capable of transmitting radio signals to a UE and receiving signals transmitted by a UE. In GSM, a Base Station Controller (BSC) controls the BTS and is connected to the Core Network. The BSC and the BTS are together called the Base Station System (BSS). In UMTS, a Radio Network Controller (RNC) controls the NodeB, and is, among other things, in charge of management of radio resources in cells for which the RNC is responsible. The RNC and its corresponding NodeBs are called the Radio Network Subsystem (RNS). The RNC is in turn also connected to the Core Network (CN). In LTE, the eNodeB manages the radio resources in the cells, and is directly connected to the CN, as well as to neighboring eNodeBs via an X2 interface.
In the discussions about Inter Radio Access Technology (IRAT) Mobility Robustness Optimization (MRO) that are currently ongoing in 3GPP RAN WG3, the following high priority use case scenarios have been chosen to be addressed as part of the Self Organizing Network (SON) Enhancements work item. These use case scenarios are summarized as follows (see R3-120390, “IRAT MRO way forward”, Huawei, RAN3 #75):                Use case 1): Failure while in LTE or during a Handover (HO) to GERAN/UTRAN, and reconnection at GERAN/UTRAN due to too late HO.        Use case 2): Failure during or after a HO from GERAN/UTRAN to LTE, which is most likely due to HO failure while moving from GERAN/UTRAN, and reconnection back at GERAN/UTRAN which is the source Radio Access Technology (RAT). The reconnection may be at a different cell than the source one. From this point on, only UTRAN will be mentioned instead of GERAN/UTRAN.        
The triggering of IRAT HO from LTE to UTRAN is controlled by parameters in LTE associated with the measurement types Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ). Hereinafter, these HO parameters are referred to as ho_thresh_lte, as the parameters typically are threshold values indicating whether a HO can be triggered. In current 3GPP specifications the only aspect of measurements used to trigger HOs is that RSRP and RSRQ may both be used. It is not specified whether one or the other or both shall be used. There may thus either be a threshold value controlling the triggering of a HO associated with RSRP, or a threshold value controlling the triggering of the HO associated with RSRQ. However, it is also possible for an operator to use both these threshold values for controlling the triggering of the HO, where one is associated with RSRP and the other is associated with RSRQ. One way to counter act the problem of use case 1), which is due to a too late HO from LTE to UTRAN, could be to increase the value of the threshold value(s) controlling the HO in order to trigger the HO earlier. The side effect of this action may be an increased number of unnecessary HOs, in cases when the LTE coverage is good enough but the connection is anyway handed over to UTRAN. An MRO algorithm should take this tradeoff into account to increase or decrease the threshold value(s) ho_thresh_lte. This tradeoff is illustrated in FIGS. 1a-c. 
FIG. 1a illustrates the problem situation of use case 1) where the threshold value for HO to UTRAN indicated by the line 101 is set such that the HO is triggered too late, at time 103, and a Radio Link Failure (RLF) occurs, at time 104, during the HO. This problem situation may initiate an MRO procedure and the threshold value controlling the HO is increased by a certain amount of dB. FIG. 1b illustrates how the increase of the threshold value to a level indicated by the line 105 leads to a successful HO to UTRAN at time 106 as the RLF is avoided. However, FIG. 1c illustrates another situation where the increase of the threshold value leads to an unnecessary HO at time 107 as the level of the LTE signal is somewhat lower only for a short amount of time after the HO to UTRAN. The situation illustrated in FIG. 1c would probably not have resulted in any RLF even if the threshold value would have been set such that the HO would have been avoided.
The triggering of IRAT HO from UTRAN to LTE is controlled by other HO parameters in UTRAN, which in this document are referred to as ho_thresh_utran. In the example case described herein, ho_thresh_utran and ho_thresh_lte are two different thresholds in the two different RATs. However, the thresholds both relates to the same signal, i.e. in this case an LTE signal. Therefore UTRAN configures the UE to measure RSRP, RSRQ or RSRP and RSRQ on the signal of a neighbour LTE cell. However, in another example the thresholds could both be related to measurements on a UTRAN signal, and the UE could be configured to measure e.g. the Received Signal Code Power (RSCP), the Received Signal Strength Indicator (RSSI), and the Ec/No defined as RSCP/RSSI instead. The problems of use case 2) described above, due to too early HOs from UTRAN to LTE, may be counteracted by increasing the value of the threshold value(s) ho_thresh_utran in order to trigger HO to LTE only when the signal is strong enough to retain the connection in LTE. However, if this threshold value is set too high, the side effect of this action may be that the UE stays an unnecessarily long time in UTRAN, i.e. that the UE is kept in UTRAN although there is enough LTE coverage for a successful HO. An MRO algorithm should also take this second tradeoff into account and increase or decrease the threshold value(s) ho_thresh_utran at the UTRAN side. This second tradeoff is illustrated in FIGS. 2a-c. 
FIG. 2a illustrates the problem situation of use case 2) where the threshold value for HO from UTRAN to LTE indicated by the line 201 is set such that the HO is triggered too early at time 202 and a Radio Link Failure (RLF) occurs after the HO at time 203. This problem situation may initiate an MRO procedure and the threshold value(s) controlling the HO is increased by a certain amount of dB. FIG. 2b illustrates how the increase of the threshold value to the level indicated by line 204 leads to that the UE is successfully kept in UTRAN and the RLF is thus avoided. However, FIG. 2c illustrates another situation where the increase of the threshold value(s) leads to that the UE is kept unnecessarily in UTRAN even though the LTE coverage is good enough for a HO.
The occurrence of both issues described above, i.e. the too late HO and the unnecessary HO, may be monitored via statistics from unnecessary HO indicators and RLF reports. Reports about unnecessary HOs are made available in LTE thanks to a function described in TS 48.018 version 11.0.0, section 11.3.115, TS 36.413 version 11.0.0, section B.1 and TS 25.413 version 11.0.0, section 9.2.1.96. The function relies on UE measurements configuration and a RAN Information Management (RIM) message sent from UTRAN to LTE. Such RLF reports must be available in the nodes running MRO. However, it is currently being discussed in 3GPP if, when, and how these reports will be available in LTE and/or UTRAN (see R3-120390, “IRAT MRO way forward”, Huawei, RAN3 #75).
Current work in 3GPP is focusing on solutions to improve mobility robustness and to avoid repeated back and forth HOs between different RATs. Such solutions are based on the identification of a mobility problem, this being a failure during mobility or repeated mobility between different RATs. However, these solutions do not take into account the consequences of adjusting mobility settings in one RAT without coordinating such adjustments in all other neighboring RATs.
Indeed, if mobility settings are changed in one RAT for the purpose of modifying mobility policies for triggering HOs towards other RATs, then equivalent and opportune changes need to be applied to neighbor RATs. The latter is to ensure a balanced system, where mobility between RATs is not subject to failures nor is too frequent or seldom.
WO2011/131225 discloses a method for reducing unnecessary HOs between cells of different RATs, based on the distribution of mobility information across various cells of different RATs. Mobility information comprises the threshold values controlling the HO. It is claimed that the threshold values may thus be configured and automatically optimized in a de-centralized way so that manual configurations and adjustments are reduced. By sending HO parameters controlling the HO from a first RAT to a second RAT from a base station in the first RAT to neighboring base stations in the second RAT, the base stations of the second RAT may make improved HO decisions e.g. avoiding ping-pong effects.